
\section{Obligation Handling Architecture}
\label{sec:Obligationhandling}
In the XACML reference architecture, the Policy Decision Point (PDP) evaluates requests sent by Policy Enforcement Point (PEP) against the policies 
stored in the Policy Administration Point (PAP). The PDP may need to query a Policy Information Point (PIP) to collect some attributes 
related to the subject, action, resource or environment.
We propose to extend XACML reference model to the model presented in Figure \ref{proposeddataflow}.
\begin{figure}[!h]
\begin{center}   
\includegraphics[scale=0.33]{dataflownew}
\caption{Proposed XACML Dataflow Diagram}
\label{proposeddataflow}
\end{center}
\end{figure}
Our extended model includes an obligation monitoring service that interacts with a reference monitor and an update module.
\begin{itemize}
\item (1) The obligation monitoring engine manages obligations states and interacts with the reference monitor that provides information about the 
the fulfillment or the obligations violation
\item (2) The update module captures any obligation state change and updates PIP attributes with some information related to obligation states and attributes 
\item (3) The PIP may update some of the policies stored in the PAP 
\end{itemize}
We consider that obligations are state machines whose different states and transitions are depicted in Figure \ref{ObligationStateMachine}.
The obligation monitoring engine handles every obligation as a state machine and thus maintains a state machine for any obligation received by the PEP.
Obligations states transitions can be described like the following:

\begin{enumerate}
\item For each obligation o returned by the PEP, we have a state transition from inactive to active.
\item If the subject fulfills the obligation then the obligation is passed
from active to fulfilled.
\item If the subject violates the obligation then the obligation is passed from active to violated.
\item After a fixed timeout, an obligation (fulfilled or violated) end.
\end{enumerate}

\begin{figure}[!h]
\begin{center}   
\includegraphics[scale=0.25]{statemachine}
\caption{Obligation State Machine}
\label{ObligationStateMachine}
\end{center}
\end{figure}

In each obligation state change, the update module sends to the PIP the following 3-tuple: 
(Obligation-Id, Obligation state, Obligation parameters) where the Obligation-Id defines the obligation identifier, the obligation state 
is the state related to the obligation current state and the obligation parameters denote the obligation subject, the obligation action, the obligation 
object and/or contextual parameters.
Taking into consideration the described architecture, access control requests will be handled like the following:
For any access request, the PDP may return the decision with a set of obligations.
If we consider that all the obligations returned by the PEP are pre-obligations and that our PEP is a Base PEP then: 
\begin{itemize}
 \item If all obligations are fulfilled, then the final decision formulated by the PEP will be permit.
 \item If there exists only a single obligation that can not be discharged by the PEP then the PEP will deny the request.
\end{itemize}
The PEP can just formulate the final decision only when all obligations returned by the PEP reach the END state.
For post-obligations, the PEP permits or denies the access and then tries the discharge the obligations.
For ongoing-obligations, the PEP tries to discharge the obligations while the access is in progress.

 
Sanctions, how they can be managed in XACML ????
 
 
 
 
 
 
 
 